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EXECUTIVE SUMMARY 



This paper is an assessment of Department of Defense (DoD) and service 
initiatives to ensure joint interoperability of Command, Control, Communications, 
Computers, and Intelligence (C4I) systems. Chapter I provides a starting point for 
readers to understand DoD and service initiatives. This chapter consists of the following 
sections: purpose of thesis, methodology, scope of thesis, definitions, background, and 
outline of chapters. This purpose of thesis section introduces and describes this paper’s 
topic and structure for the reader, and the research methodology section gives the reader a 
reference perspective for the research and analysis conducted. The scope of thesis section 
develops the boundaries for the thesis and research. The definitions and background 
sections list Joint Publication 1-02 definitions that directly apply and establish a broad 
base for the reader to understand both DoD and service initiatives. Within the 
background section, overviews of the C4I for the Warrior (C4IFTW) concept, DoD 
Technical Architecture for Information Management (TAFIM), DoD interrelated 
architectures, Joint Technical Architecture (JTA), and levels of information system (IS) 
interoperability are provided. 

Chapter II addresses the US Air Force perspective. This chapter contains the 
following sections: vision, architectures, capabilities planning and architecture 

management, and conclusion. The vision section introduces the Air Force’s HORIZON 
concept. The architectures section is subdivided into operational, technical, and systems 
sections to identify service applications. The capabilities planning and architecture 
management section describes processes established to support the development of 
interoperable systems; lastly, the conclusion section recognizes that Air Force initiatives 
are evolving. 

Chapter III reviews Army initiatives and is divided into the following sections: 
vision, architectures, and conclusion. The vision section summarizes the Army’s 
Enterprise Strategy, both vision and implementation plan. The architectures section 
presents the Army’s view of interrelated architectures to support the development of 
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interoperable systems, and the conclusion section acknowledges that Army initiatives 
have a well-established starting base and are continually evolving. 

Chapter IV presents the US Navy, to include the US Marine Corps. This chapter 
contains vision, architecture, and conclusion sections. The vision section outlines the 
Navy and Marine Corps’ Copernicus strategy, and the architecture section presents the 
application of recognized DoD architectures used to achieve joint C4I interoperability. 
Finally, the conclusion section identifies that Navy and Marine Corps interoperability 
initiatives are progressing. 

Chapters I - IV provide a broad knowledge base of both DoD and service actions 
to achieve joint C4I system interoperability. Chapter V builds on this to conduct a 
consolidated analysis of the entire action spectrum. Five examples are presented to 
illustrate that all C4I systems are not the same— each system has its own unique functional 
characteristics. This chapter contains the following sections: consolidated initiative 

summary, similarities and differences, positive actions, further definitions, mission- 
specific examples, and summary. The consolidated initiative summary section presents a 
vision, action, and baseline action matrix to analyze DoD and service initiatives. The 
similarities and differences and positive actions sections provide comments based on the 
consolidated analysis, while the further definition section identifies areas requiring 
additional development. Within the mission-specific examples section, five C4I systems 
that require very different functional parameters to support mission objectives are 
presented. Each example system subsection is divided into scenario, objective, mission 
analysis, and conclusions, and examples are further compared using a mission-specific 
area matrix. The summary section highlights the analysis observations. 

Finally, Chapter VI contains conclusions, recommendations, and further areas of 
research. Building on the previous five chapters, this chapter identifies critical issues, 
provides direction, and recommends research areas requiring analysis. The conclusions 
section formalizes identified analysis and observations, and the recommendations section 
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presents three initiatives to enhance the development of joint C4I systems. Lastly, the 
further research section identifies four areas of study for DoD graduate students. 
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I. INTRODUCTION 



The time is ripe to set a course to resolve our C4I interoperability 
issues. [Ref. 1] 

Colin L. Powell 

Chairman of the Joint Chiefs of Staff 
12 June 1992 



A. PURPOSE OF THESIS 

To paraphrase General Colin L. Powell (Retired), the time is ripe to quantitatively 
define interoperability. Not all Command, Control, Communications, Computer, and 
Intelligence (C4I) systems are the same. Mission-specific requirements dictate whether a 
system is interoperable or not. The current interoperability definition is quite vague for 
mission-specific C4I systems, and existing Department of Defense (DoD) and service 
initiatives only address general guidance to focus system development. Quantifiable 
parameters must be articulated for all systems to ensure interoperability. This paper 
reviews current initiatives, provides an assessment of these initiatives, presents five 
common examples of mission-specific requirements, and outlines a framework to better 
quantify system parameters for planners, designers, and developers. 

Chapter I provides a starting point for readers to understand DoD and service 
initiatives. This chapter consists of the following sections: purpose of thesis, 
methodology, scope of thesis, definitions, background, and outline of chapters. This 
section, purpose of thesis, introduces and describes this paper’s topic and structure for the 
reader. The research methodology section gives the reader a reference perspective for the 
research and analysis conducted. The scope of thesis section develops the boundaries for 
the thesis and research. The definitions section lists Joint Publication 1 -02 definitions that 
directly apply, and the background section establishes a broad base for the reader to 
understand both DoD and service initiatives. Within the background section, overviews 
of the C4I for the Warrior (C4IFTW) concept, DoD Technical Architecture for 
Information Management (TAFIM), DoD interrelated architectures. Joint Technical 
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Architecture (JTA), and levels of information system (IS) interoperability are provided. 
The last section outlines the five chapters that follow. 

Chapter II addresses the US Air Force perspective. Chapter III reviews the US 
Army, and Chapter IV presents the US Navy, to include the US Marine Corps. Chapter V 
is a consolidated analysis with examples that identify the need for mission-specific C4I 
system profiles, and quantifiable interoperability parameters. Finally, Chapter VI contains 
conclusions, recommendations, and further areas of research. 

B. METHODOLOGY 

Using a consolidated initiative matrix, both DoD and service visions and actions 
are reviewed to identify intent. More importantly, existing documents used by C4I system 
planners, designers, and developers are assessed against essential system development 
criteria, and required baseline actions, to achieve interoperability. Findings reveal that 
interoperability development guidance and tools do not address mission-specific 
parameters of C4I systems. Common mission-specific cases are provided and 
demonstrate that achieving interoperability is more than general guidance and more than 
the ability to pass data or information through seamless interfaces to ensure that systems 
are functional. Therefore, interoperability must be further defined by analyzing a C4I 
system’s unique mission. Finally, to guide C4I system design, a framework to establish 
quantifiable thresholds is developed and presented using existing joint doctrine. 

With the research methodology given, the following questions were proposed: 

• Is the current definition of interoperability adequate to ensure the seamless 
integration of C4I systems? 

• What are the DoD and service initiatives to ensure C4I system 
interoperability? 

• Are there differences in initiatives? If so, why and how do these differences 
compare? 

• Are items, such as system interfaces and timing requirements, adequately 
articulated through existing modeling techniques? 
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• Should system modeling be more than defining data elements? 

• Should there be interoperability profiles based on quantifiable parameters? 

C. SCOPE OF THESIS 

As previously mentioned, this paper is an assessment of combined DoD and 
service initiatives to ensure joint interoperability of C4I systems. Directives, guidance, 
and technical architectures have been developed to conform to service initiatives in a 
positive direction, but general definition is not enough. The detail of interoperability 
differs for each mission-specific case. For a C4I system to be functional, certain system 
parametric requirements must be met. With the vast amount of participants, standards, 
and systems involved, solid general guidance enhances the development of interoperable 
systems, but every system is not the same. 

D. DEFINITIONS 

Joint Publication 1-02 defines the following terms: 

1. Architecture 

A framework or structure that portrays relationships among all the elements of the 
subject force, system, or activity. [Ref. 2] 

2. Command, Control, Communications, and Computer Systems 

Integrated systems of doctrine, procedures, organizational structures, personnel, 

equipment, facilities, and communications designed to support a commander’s exercise of 
command and control across the range of military operations. Also called C4 systems. 
[Ref. 2] 

3. Interoperability 

• The ability of systems, units, or forces to provide services to and accept 
services from other systems, units, or forces and to use the services so 
exchanged to enable them to operate effectively together. 

• The condition achieved among communications-electronics equipment when 
information or services can be exchanged directly and satisfactorily between 



3 



them and/or their users. The degree of interoperability should be defined when 
referring to specific cases. [Ref. 2] 

4. Tactical Command, Control, Communications, and Computer 

Systems 

The facilities, equipment, communications, procedures, and personnel essential to 
theater level and below commanders for planning, directing, and controlling operations of 
assigned and attached forces pursuant to the mission assigned and which provide(s) for 
the conveyance and/or exchange of data and information from one person or force to 
another. [Ref. 2] 

E. BACKGROUND 

It is DoD policy to acquire quality products that satisfy the needs of the 
operational user with measurable improvements to mission accomplishment. [Ref. 3] The 
application of this concept is true for the entire acquisition process and is a cornerstone 
for interoperability. The threat to the United States has drastically changed, and the way 
the services fight has been altered to meet this challenge. No longer are there single 
service operations. Today, a multi-service force meets mission objectives in several 
operational environments— the battlespace. To better support and improve mission 
accomplishment, the Joint Staff developed the C4I for the Warrior (C4IFTW) concept. 

1 . C4I for the Warrior (C4IFTW) 

The unifying theme of the C4IFTW concept is to achieve global interoperability that will: 
allow any Warrior to perform any mission at any time, and any place; be responsive, and 
reliable, secure; and be affordable. [Ref. 1] 

This concept addresses joint force C4I interoperability issues in a evolutionary 
manner. Building upon lessons learned from previous conflicts, rapidly changing 
technology, and the changing national security strategy, this concept provides a three 
phase roadmap to achieve total interoperability of C4I systems. Figure 1 illustrates the 
Joint Task Force (JTF) C4I objective. The phases of the roadmap are: Quick Fix Phase, 
Mid-Term Phase, and Objective Phase. [Ref. 1] 
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Figure 1. Joint Task Force C4I Objective [From Ref. 1] 

The focus of the Quick Fix Phase was to be achieve interoperability of existing 
systems. [Ref 1] In 1993, this phase was considered a success based on the following 
actions: translators and interpreters were developed along with data base interoperability, 
C4I requirements and architectures were synchronized, and a solid foundation of joint 
interoperability policy and doctrine was established. [Ref. 4] Items, such as DoD 
Directive 4630.5, DoD Instruction 4630.8, Joint Publications 6-0 and 6-02, joint training 
exercises, and the Joint Warrior Interoperability Demonstrations (JWIDs) are products of 
this phase. 

Within the current Mid-Term Phase, total interoperability must be achieved for 
new C4I systems during development, testing, acquisition, and implementation. 
Additionally, this includes establishing a joint wide area network based on digital 
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commonality — the Global Command and Control System (GCCS). [Ref. 4] This phase is 
continually evolving with changing technology, new directives, and updated standards. 

Finally, using the experience gained in the first two phases and advancing 
technologies, the Objective Phase addresses optimizing C4I support for the Warrior. The 
objectives are to create a multi-functional, multimedia terminal fitted to the Warrior’s 
manprint, a fully integrated tactical picture based on fused information from the 
battlespace and an integrated global infosphere. [Ref. 4] 

2. DOD Technical Architecture for Information Management (TAFIM) 

The Technical Architecture for Information Management (TAFIM) is designed to 
guide the development of the DoD infrastructure. It provides the services, standards, 
design concepts, components, and configurations to guide the development of technical 
architectures. The TAFIM promotes interoperability of information systems, but does not 
address mission-specific applications/systems. Within the DoD, using the TAFIM is 
mandatory. If everyone follows the DoD directive to use it, more C4I systems will 
become more interoperable. The proper application of the TAFIM is expected to: [Ref 5] 

• Promote integration, interoperability, modularity, and flexibility 

• Guide acquisition and reuse 

• Speed the delivery of information technology with lower costs 

The TAFIM Version 2.0 is divided into the following volumes: Volume 1, 
Overview, Volume 2, Technical Reference Model, a conceptual model for information 
system services and their interfaces; Volume 3, Architecture Concepts and Design 
Guidance, concepts and guidance to support the development of technical architectures; 
Volume 4, DoD Standards-Based Architecture Planning Guide, a standards-based 
architecture planning methodology; Volume 5, Support Plan, describes how to use 
TAFIM guidance for acquisition (Draft); Volume 6, DoD Global Security Architecture, 
common DoD security requirements; Volume 7, Information Technology Standards 
Guidance, DoD profile of standards; and Volume 8, DoD Human Computer Interface 
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(HCI) Style Guide , a common framework for HCI design and implementation. [Ref. 5] 
TAFIM, Version 3.0 Draft, is currently posted for review on the world wide web 
(WWW). 

3. DOD Interrelated Architectures 

With the rapid growth of architectures in recent years, the DoD defined an 
interrelated set of architectures to support the development of interoperable systems: 
Operational, Technical, and Systems. The Operational Architecture describes the tasks, 
operational elements, and information flows required to accomplish or support a 
warfighter function. The Technical Architecture is the minimal set of rules that governs 
the arrangement, interaction, and interdependence of the parts or elements whose purpose 
is to ensure that a system satisfies a specified set of requirements. The Systems 
Architecture is the descriptions, including graphics, of systems and interconnections 
providing for or supporting a warfighting functions. Figure 2 illustrates the relationships 
of these architectures. [Ref. 6] 




Operational i 

Aichfteptare 



> Operational Architecture (O A) is the total 
aggregation of missions, functions, tasks, 

information requirements, and business 

- 

f :-G ' ■ ~ 

_ . rchitecture is the ’’building 
non which systems are based 

> Systems Architecture is the physical 
implementation of the OA, the layout and 
relationship of systems and 
communications 



Technical 

Architecture 




Figure 2. Relationships of Architectures [From Ref. 6] 

4. Joint Technical Architecture (JTA) 

On 12 March 1996, the Joint Technical Architecture (JTA), Version 0.5 
Preliminary Draft, was posted for evaluation on the WWW. This document was 
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developed by a working group using the Army’s Technical Architecture (ATA) as a 
starting point; the ATA will be covered in Chapter III. The JTA has three mutually 
supporting objectives: [Ref. 6] 

• To provide the foundation for a seamless flow of information and 
interoperability among all tactical, strategic, and sustaining base systems that 
produce, use, or exchange information electronically. 

• To mandate standards and provide guidelines for system development and 
acquisition which will significantly reduce cost, development time, and 
fielding time for improved systems. 

• To influence the direction of the information industry's technology 
development by stating the DoD's direction and research and development 
investment so that it can be more readily leveraged in systems within DoD. 

Eventually, the JTA will apply to all systems that produce, use, or exchange 
information electronically. This initial version is focused on C4I systems and their 
interfaces with other entities, such as weapon systems, sensors, office automation 
systems, etc., to support interoperability. Operational requirements developers will use 
the JTA to guide the development of requirements and functional descriptions. System 
developers will use the JTA to ensure that new and upgraded systems meet established 
interoperability requirements, and system integrators will use this document to facilitate 
the integration of both existing and new systems. 

The JTA contains the following seven sections: Overview, Information 
Processing Standards, Information Transfer Standards, Information Modeling and Data 
Exchange Standards, Human-Computer Interfaces, Information Systems Security, and 
Emerging Standards. [Ref. 6] 

Section 4, Information Modeling and Data Exchange Standards, identifies the 
minimum information standards applicable to information modeling and exchange of 
information for all DoD programs. The Integrated Definition (IDEF) modeling methods 
have been adopted by the DoD to support the identification of information and 
information exchange requirements for the development of interoperable systems. Federal 
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Information Processing (FIPS) Publication 183, Integration Definition for Function 
Modeling (IDEFO), is used to guide activity modeling, while FIPS Publication 184, 
Definition for Information Modeling (IDEF1X), is used to govern data modeling. Using a 
common language, IDEFO activity models capture an organization’s processes at the 
highest logical levels. Processes are further decomposed into lower logical levels to 
uncover supporting processes. [Ref. 6] 

The DoD created the Defense Data Dictionary System (DDDS) to provide a single 
authoritative source for data standards. Managed by DISA, the DDDS, a DoD-wide 
central data base, includes standard data entities and elements and access to data models. 
Also, the DDDS is used to collect individual data standards and document content and 
format for data elements. An objective view of how the adopted modeling methods and 
data standards will support the development of interoperable systems is depicted in 
Figure 3. 



Deflnes Information Uses Standard 




Figure 3. Objective Information Standards Technical Architecture [From Ref. 6] 
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5. Levels of Information System (IS) Interoperability 

In 1993, DoD services and agencies realized that the existing interoperability 
definition was insufficient. As a result, a simple six-level construct was developed to 
describe different levels of interoperability. Figure 4 provides a description of these levels 
along with enabling capabilities for each level. [Ref. 7] 
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Figure 4. Levels of Interoperability (circa 1993) [From Ref. 7] 



In April 1995, the Joint Interoperability Test Center (JITC) expressed an interest 
in pursuing the levels construct as a basis for joint systems certification, and recently, the 
C4I Surveillance and Reconnaissance Integration Task Force (C4ISR ITF) endorsed the 
concept. The MITRE Corporation recently updated the concept to integrate the planned 
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functions of the Defense Information Infrastructure (DII), emerging Internet services, and 
six NATO interoperability levels. Currently, MITRE is coordinating with key DoD 
organizations for levels refinement. [Ref. 7] Figure 5 depicts the revised levels construct. 

The revised construct contains three interoperability categories: transaction, 
service, and application. The transaction category addresses the ability to establish a 
connection between discrete systems and conduct basic exchanges of data. The service 
category addresses the interoperability effects of: distributed computing services, 
community leveraging of common solutions, establishing standard system and user 
interfaces, and exchanging more complex data types. Finally, the application category 
addresses the establishment of the C4ISR IS objective based on C4IFTW vision. [Ref. 7] 
The categories are further subdivided into levels as annotated in Figure 5. 
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Figure 5. Revised IS Levels Construct [From Ref. 7] 
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F. 



OUTLINE OF CHAPTERS 



1. Chapter II - United States Air Force 

This chapter summarizes the US Air Force’s HORIZON vision and supporting 
actions to achieve interoperability. The service perspective and existing tools in use are 
described to outline the Air Force’s perspective to develop interoperable systems. 

2. Chapter III - United States Army 

The US Army’s Enterprise vision and implementation plan are presented along 
with the established processes to achieve the development of interoperable systems. 

3. Chapter IV - United States Navy and Marine Corps 

The Copernicus vision and Marine Corps Technical Architecture are discussed to 
outline the US Navy and Marine Corps’ actions to ensure the development of 
interoperable C4I systems. 

4. Chapter V - Analysis 

Chapter V provides a consolidated view of the DoD and service initiatives to 
address interoperability of C4I systems. Documented actions are compared and 
consolidated within an analytical matrix format. Mission-specific interoperability profiles 
are presented to clearly identify that individual system requirements may require different 
design parameters for systems to function. 

5. Chapter VI - Conclusions and Recommendations 

This chapter contains conclusions, recommendations, and further research areas 
based on the Chapter V analysis. A framework to quantify C4I system parameters is 
outlined. 
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II. UNITED STATES AIR FORCE 



History has shown that the side that effectively analyzes, decides, and 
acts the fastest will prevail in any conflict. We can and must make 
optimum use of information technology to operate inside any opponent’s 
decision cycle. [Ref. 8] 

Ronald R. Fogleman 
USAF Chief of Staff 
August 1995 

A. INTRODUCTION 

With the world changing, information is becoming a new center of gravity — a 
strategic asset, inviting attack and requiring protection. Before, warfare was only 
considered in air, land, sea, and space operational environments, but the Air Force has 
now recognized information as a fifth operational environment. Information dominance is 
crucial to military success across the spectrum of conflict. [Ref. 8] 

Chapter II contains the following sections: vision, architectures, capabilities 
planning and architecture management, and conclusion. The vision section introduces the 
Air Force’s HORIZON concept. The architecture section is subdivided into operational, 
technical, and systems sections to identify service applications. The capabilities planning 
and architecture management section describes processes established to support the 
development of interoperable systems; lastly, the conclusion section recognizes that Air 
Force initiatives are evolving. 

B. VISION 

In 1993, realizing the importance of information technology, the US Air Force 
developed the HORIZON concept as an extension of the Joint Staff s C4I for the Warrior 
(C4IFTW) construct for joint interoperability. This concept focused on information 
architectures to develop an integrated and responsive global infosphere that supports both 
Global Reach and Global Power objectives. For the first time, the Air Force sought to 
define a path to a service-wide architecture of C4I systems. This past year, the Air Force 
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updated their vision with C4I HORIZON ’95. This document expands the previous 
HORIZON vision by establishing 21 st century information infrastructure objectives and 
plans for rapid integration of evolving technology within the current and future 
infrastructure. C4I HORIZON ’95 contains the visions for achieving information 
superiority and leading the US Air Force into the information age. This updated edition 
defines a planning perspective and evolutionary path for information systems and the 
application of information technology across the spectrum of Air Force operations. [Ref. 
8 ] 

C. ARCHITECTURES 

With the vision to seamlessly integrate information systems, the Air Force created 
a framework to coordinate and integrate related major command (MAJCOM) information 
architectures. As defined by the Defense Science Board, and previously mentioned in 
Chapter I, background section, the Air Force adopted the three broad constructs for 
information requirements and planning: operational, technical, and system architectures. 
[Ref. 8] 

1. Operational 

The Air Force models operational architectures that represent a description of the 
tasks, operational elements, and information flows required to accomplish or support a 
warfighting function. [Ref. 8] 

2. Technical 

The Air Force is currently drafting a service technical architecture that will be released 
for review on the WWW in May or June 1996. The architecture will reflect a minimal set 
of rules governing the arrangement, interaction, and interdependence of the parts or 
elements of a system. [Ref. 8] Until the service technical architecture is finalized, C4I 
system designers are required to use established technical reference codes (TRCs). To 
assist C4 systems designers during acquisition and modification of C4I systems, the 
USAF created TRCs. TRCs are a set of reference documents containing policy, 
directives, transition guidance and standards that designers can easily access using 
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various web browsers on the WWW. They assist planners with standardizing systems to 
ensure interoperability of future developments. TRCs bring together government and 
non-government standards and Air Force and DoD policies and guidance for C4I systems 
and system components of both fixed and deployed systems. TRCs are based on the 
TAFIM, and they articulate standards to ensure interoperability. Through the process of 
combining standards and interoperability related documents, a detailed profile is created 
for almost every conceivable system; therefore, solid guidance for interoperability is 
provided. [Ref. 9] 

There are two types of TRCs: Component and Service. Information for 
Component TRCs is organized by categories of system components, and information for 
Service TRCs is organized by user C4I system capability. Usually, Component TRCs are 
used for smaller acquisitions and piece-part buys, while Service TRCs address larger 
acquisitions and procurement of a C4I user requirement capability. [Ref. 9] Table 1 
outlines the orientations of both TRC types. 



Service TRCs Tend to Address: 


Component TRCs Tend to Address: 


Larger Acquisitions 


Smaller Acquisitions 


Entire C4I Systems 


Individual Components of C4I Systems 


Broad-Based Ideas 


Commercial-Off-The-Shelf Solutions 


Abstract Interoperability Guidance 


Interoperability Guidance For Specific Components 


Concerns For System Designs 


Strategies For Meeting The Specifications of 
System Design 



Table 1. Orientation of Service and Component TRCs [From Ref. 9] 



As users access TRCs for information, they start with top level requirements and 
move down the tree structure depicted in Figure 6. Depending on the level of detail and 
information required, users may have to reference one or more sub-levels to collect all 
necessary standards. This may require access to both Component and Service TRCs. 
[Ref. 9] 
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Figure 6. TRC Tree Structure [After Ref. 9) 
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3. Systems 

The Air Force further defines their C4I systems through system architectures. 
These architectures provide a description, including graphics, of the systems and 
interconnections providing for or supporting a warfighter function. [Ref. 8] 

D. CAPABILITIES PLANNING AND ARCHITECTURE MANAGEMENT 

The C4I capabilities planning process. Figure 7, is designed to link operational 
needs to architectures, and provide a top-level, enterprise-wide view, so systems 
architects may design fully integrated joint C4I systems. [Ref. 8] Automated tools are 
used to display, analyze, and manage key architecture elements and interconnections 
within the service and external entities, such as other DoD organizations and coalition 
forces. [Ref. 8] 
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Figure 7. C4I Capabilities Planning Process [From Ref. 10[ 



The Air Force is institutionalizing C4I Codes, Permits, and Inspections (CPI) to 
ensure that C4I capabilities and architectures are used throughout the requirements, 
acquisition, and testing processes. This guides system acquisition to ensure developers 
follow established building codes. [Ref. 8] 
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Figure 8 illustrates the HORIZON architecture management process. Within this 
process, a database is used to develop service-wide architectures. Eventually, the database 
will be automatically updated from MAJCOM architectural activity databases and tools. 
Emerging modeling and simulation techniques are used to facilitate architecture 
development. [Ref. 8] 
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Figure 8. HORIZON Architecture Management Process [From Ref. 8] 



E. CONCLUSION 

The Air Force’s strategy to ensure interoperability is continuously evolving. Many 
actions outlined within the HORIZON vision have taken place, while others are currently 
being developed and refined. To better guide Air Force personnel through C4I capability 
development, paperless information sharing is established via the WWW. 
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III. UNITED STATES ARMY 



As we know, the challenges of joint interoperability are great. The 
Enterprise Strategy is the framework by which we will meet and conquer 
these challenges. It is a vision for present and future information support 
for our Total Army. [Ref 11] 

Gordon R. Sullivan 
General, United States Army 
Chief of Staff 
20 July 1993 

A. INTRODUCTION 

Recent history and changes in the world have altered the focus for today’s armed 
forces. Today’s threats are less defined and pose unique challenges for warfighters to 
counter. From the Army’s view, countering tomorrow’s threats requires “Winning the 
Battlefield Information War.”[Ref. 1 1] 

Chapter III is divided into the following sections: vision, architectures, and 

conclusion. The vision section summarizes the Army’s Enterprise Strategy, both vision 
and implementation plan. The architectures section presents the Army’s view of 
interrelated architectures to support the development of interoperable systems, and the 
conclusion section acknowledges that Army initiatives have a well-established starting 
base and are continually evolving. 

B. VISION 

As stated in Army Enterprise Strategy: The Vision, the purpose of the Army 

Enterprise Strategy is to support US Army warfighters into the 21st century. The strategy 
is designed to: unify the C4I community toward a common goal; establish a structure to 
guide the system development process; develop economic, functional, and technical 
guidelines and criteria to aid resource managers in making C4I system assessments; and 
provide a broad systems perspective across DoD. [Ref. 1 1] 

As previously mentioned, for the Army to counter today’s threats, warfighters 
must “Win the Battlefield Information War.” Through the exploitation of information 
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technology, this goal is achievable. That is why the Enterprise Strategy focuses on 
identifying, supplying, and implementing sophisticated information and other C4I 
technologies in support of the warfighter. [Ref. 11] 

The Enterprise Strategy contains both a vision and an implementation plan. The 
vision introduces and explains ten principles needed to ensure the warfighter has 
information superiority over any adversary. The following principles are exclusively 
taken from the Enterprise vision document: [Ref. 1 1] 

• Focus on the Warfighter - Provide the Warfighter C4I systems that meet 
validated needs. 

• Ensure Joint Interoperability - Provide the Warfighter C4I systems that 
interoperate in Joint and Combined operations. 

• Capitalize on Space-Based Assets - Provide the Warfighter assured access to 
mission essential military and commercial space-based systems that support 
the Force Projection Army across the entire operational continuum. 

• Digitize the Battlefield - Provide the Warfighter an integrated digital 
information network that supports warfighting systems and assures C2 
decision-cycle superiority. 

• Modernize Power Projection Platforms - Provide the Warfighter a modem 
power projection platform to support peacetime operations, mobilization, 
force projection, split-base operations, and redeployment. 

• Optimize the Information Technology Environment - Provide the Warfighter 
with more efficient information support for combat and peacetime operations. 

• Implement Multi-Level Security - Provide the Warfighter the ability to access 
and exchange information at needed levels of classification using a single C4I 
system. 

• Acquire Integrated Systems Using Commercial Technology - Provide the 
Warfighter C4I capabilities that leverage commercial technology. 

• Ensure Spectrum Supremacy - Provide the Warfighter electromagnetic 
spectrum supremacy in order to maximize the benefits of maneuver and tempo 
in conjunction with firepower. 
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• Exploit Modeling and Simulation - Provide the Warfighter with cost effective 
training, testing, and rapid prototyping through state-of-the-art modeling and 
simulation. 

As indicated by the principles, the present and future ways the Army intends to 
conduct military operations is going through a dramatic change. The operational 
environment is no longer a localized area or geographically contained. The intelligent 
application of Information Age technology will equip warfighters with the necessary 
tools to access critical information and enhance coordination for the successful execution 
of joint or combined operations. 

Based on the sound principles established within the vision, the implementation 
plan provides an assessment of existing systems, an investment strategy or blueprint for 
the future, and an action plan to implement the strategy. Specific tasks are identified and 
responsibilities are assigned to focus a unified effort. [Ref. 12] 

C. ARCHITECTURES 

Due to the rapid growth of architectures within the C4I and information system 
communities in recent years, the Army Science Board (ASB) conducted a study in the 
Summer of 1994. As a result, an interrelated set of architectures was defined: 
Operational, Systems, and Technical. As mentioned in Chapter I, these concepts were 
adopted by the DoD as well as the Army Enterprise Strategy. [Ref. 13] Figure 9 
illustrates the relationship among these architectures. This figure along with the 
architecture definitions differ slightly from Figure 2, Relationships of Architectures, and 
definitions presented in Chapter I; the Army Technical Architecture (ATA) was the 
starting point for the JTA and has been further developed with other service documents 
by a multi-service committee to support the joint community. [Ref. 6] The following 
architecture definitions were exclusively taken from the ATA. 

1. Operational 

The Operational Architecture, often graphical, describes force elements and 
information exchange requirements between these elements. [Ref. 13] The Army is 
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currently developing these architectures based on the Force XXI initiative, a 
reconceptualization and redesign of the force at all echelons. The application of 
advanced technology on today’s modem battlefield is altering these architectures. 
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Figure 9. Different Architectures [From Ref. 13] 



2. Technical 

As defined in the ATA, the Technical Architecture is the minimal set of rules that 
governs the arrangement, interaction, and interdependence of the parts or elements that 
together may be used to form an information system. The ATA is recognized as a set of 
“building codes” and applies to all systems that produce, use, or exchange information 
electronically. Released 30 January 1996, Version 4.0 is based on the TAFIM, DoD 
Directive 8320-series governing standardization, and the Army’s initiatives to streamline 
the acquisition process. Articulated in the ATA are three mutually supporting objectives: 
[Ref. 13] 



• To provide the foundation for seamless flow of information and 
interoperability among all tactical, strategic, and sustaining base systems that 
produce, use, or exchange information electronically. 
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• To provide guidelines and standards for system development and acquisition 
that will dramatically reduce cost, development time, and fielding time for 
improved systems. 

• To influence the direction of the information industry’s technology 
development and research and development investment so that it can be more 
readily leveraged in Army systems. 

The ATA consists of the following six sections: Overview, Information 

Processing Standards, Information Modeling and Data Exchange Standards, Human- 
Computer Interfaces, and Information Security. 

3. System 

The Systems Architecture is the description, including graphics, of the systems 
solution used to satisfy the warfighter’s Operational Architecture requirement. 

D. CONCLUSION 

The Army Enterprise Strategy starts with sound principles to establish a tightly 
focused vision for the Army C4I community. By using a process-oriented view for joint 
C4I systems development, the Army will achieve intended objectives outlined within the 
Enterprise Strategy. As with all initiatives concerning interoperability within DoD, the 
process is evolving. 
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IV. UNITED STATES NAVY AND MARINE CORPS 



We have to be able to adapt quickly to changing technology to fight 
and win wars in the Information Age. It is clear that information has 
become a major factor in warfare and will grow in importance in the next 
century. [Ref. 14] 

Admiral J. M. Boorda, USN 
Chief of Naval Operations 
February 1996 

A. INTRODUCTION 

As the Information Age emerged, the US Navy recognized the potential of using 
information as a warfighting tool. In response, the Navy developed a strategy to make 
C4I systems more responsive for the warfighter. For modem warfare in the joint 
battlespace, the requirement for information dominance has become essential. 
Information-based warfare allows warfighters to increase the operational tempo of battle 
by exploiting advanced weapons technology. [Ref. 14] 

This chapter contains vision, architecture, and conclusion sections. The vision 
section outlines the Navy and Marine Corps’ Copernicus strategy, and the architecture 
section presents the application of recognized DoD architectures used to achieve joint C4I 
interoperability. Finally, the conclusion section identifies that Navy and Marine Corps 
interoperability initiatives are progressing. 

B. VISION 

Copernicus provides a focus for the Navy and Marine Corps to make C4I systems 
more responsive to the warfighter, to field C4I systems more quickly, to capitalize on the 
advances of technology, and to shape doctrine with these changes. In 1992, the Navy and 
Marine Corps team published ‘‘...From the Sea, ” and along with Copernicus, these 
documents reflect the shift from a maritime, open-ocean warfighting environment to joint 
operations in the littoral. Copernicus is designed as a user-centered C4I information 
management architecture; this provides a framework for capturing technological change. 
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[Ref. 14] Warfighters are supported at all levels: watchstander, shore commanders, 
Composite Warfare Commanders (CWC), and Commander Joint Task Force (CJTF). 

Exclusively defined in Copernicus... Forward, Copernicus contains the following 
five essential elements that provide architectural oversight to leverage the C4I 
infrastructure effectively and enhance the C4I operational perspective. [Ref. 14] 

• Seamlessly blend, through common applications in one workstation, critical 
tactical, operational and administrative data to the warfighter, thus allowing 
tactical objectives to drive operations. 

• Assimilate required information rapidly through standardized data formats, 
permitting operational commanders and users to "pull" desired information to 
accomplish tasks. A two-way intelligent "push" capability supplements user- 
pull when required and prevents information overload. 

• Provide information using integrated data formats in a multimedia 
environment where form fits function (i.e., voice, video, imagery, and tactical 
data at high speeds). 

• Provide a common operating environment (COE) that standardizes 
workstations for the operator. Workstation and user interface standardization 
permits greater operator proficiency while reducing training requirements. 

• Use common building blocks for modular and standardized hardware design, 
which permit upgrades and additions to the architecture in an expeditious 
manner. 

Copernicus, a framework of five interactive pillars, links command and control 
processes at all echelons of command. The pillars include: Global Information Exchange 
System (GLOBIXS), a system that supports commanders through access to a series of 
wide area Defense Communications System (DCS) networks; CINC Command Complex 
(CCC), a primary gateway for communications and information flow from GLOBIXS to 
deployed forces via Tactical Data Information Exchange System (TADIXS); TADIXS, 
tactical networks connecting to the CCCs with the Tactical Command Centers (TCCs); 
TCC, a forward deployed command center, ashore or afloat, that disseminates 
information to the warfighter; and Battlecube Information Exchange System (BCIXS), a 
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system that supports the battlecube in which tactical forces operate. [Ref. 14] Figure 10 
depicts the pillars of Copernicus. 
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Figure 10. Pillars of Copernicus [From Ref. 14] 



Copernicus provides four essential C4I functions: common tactical picture (CTP), 
connectivity, sensor-to-shooter, and information warfare (IW). The CTP is the 
information from sensors to the shooter that allows the tactical commander to understand 
the battlespace, and connectivity links communications nodes to implement the sensor-to- 
shooter construct. This construct focuses on the process of putting the weapon on target. 
The migration of the decision-making process from upper echelons down to the tactical 
commander, or shooter, provides a true sensor-to-shooter environment. As illustrated in 
Figure 11, the span of control compresses under the sensor-to-shooter construct. Finally, 
information warfare (IW) is any action to confuse or destroy the enemy’s information 
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and/or information systems while leveraging and protecting friendly information and/or 
information systems to achieve information dominance. [Ref. 14] 
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Figure 11. Span of Control [From Ref. 14] 



C. ARCHITECTURES 

As defined by the Defense Science Board, and previously mentioned in Chapter I, 
background section, the Navy adopted the three broad constructs for information 
requirements and planning: operational, technical, and system architectures. 

1. Operational 

The Navy and Marine model operational architectures that represent a description 
of the tasks, operational elements, and information flows required to accomplish or 
support a warfighting function. 
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2. Technical 

The Navy does not have a technical architecture, but expects to fully embrace the 
JTA as the draft becomes final. Currently, the TAFIM, supplemented with Naval 
publications, is used to guide system development. For example, the Naval Warfare 
Tactical Database (NWTDB) Standards Manual provides data element formats and inter- 
system database exchange structures for system developers, database producers, and 
operational users. It contains administrative information needed to integrate standards 
into existing systems, data models, data sets, and data elements that support the evolving 
DoD standards. [Ref. 15] 

Figure 12 is the Navy’s objective C4I database architecture. This shows a 
common interface language or data transfer structure that is required to support common 
processing in an open systems environment. The database architecture is composed of: 
standardized data elements, which facilitate the exchange of data by automated systems; 
normalized logical structure, which provides a standard for human and machine to relate 
and exchange data; and designated sources, for the production of reference data. [Ref. 1 5] 

In October 1995, the Marine Corps published a technical architecture that applies 
to all Marine Corps programs for Command and Control (C2) systems. This document 
provides a minimal set of rules for system development and is designed to ensure 
interoperability among operating forces, the Marine Corps supporting establishment, and 
joint C2 systems. The architecture leverages commercial technology and defines Marine 
Corps specific standards where joint standards do not exist. As with all interoperability 
documents, this one is continually evolving and future versions will reflect changes in 
Navy and Marine Corps efforts and interoperability requirements with other DoD 
agencies. [Ref. 16] 

This Marine Corps Technical Architecture (MCTA) is divided into the following 
sections: Overview, Information Processing Standards, Information Transfer Standards, 
Information Standards, Marine-Machine Interfaces, and Minimum Desktop Computer 
Configuration and Software Product Requirements. 
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Figure 12. Objective C4I Database Architecture [From Ref. 15] 



3. System 

The Navy and Marine Corps use systems architectures as descriptions, including 
graphics, of systems and interconnections providing for or supporting warfighting 
functions. 
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D. CONCLUSION 



Copernicus, the Navy and Marine Corps strategy to achieve joint C4I 
interoperability, is fielded and operational, but is continually evolving. Recently, key 
agencies from the Navy and Marine Corps met to focus Copernicus efforts toward 
improving support for the Navy and Marine team. By leveraging commercial technology 
and following simple rules for C4I development, interoperability will be achieved and 
will lower the cost of information by optimizing a system’s ability to reach more users. 
[Ref. 16] 
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V. ANALYSIS 



A. INTRODUCTION 

The previous chapters introduced and provided a broad knowledge base of both 
DoD and service actions to achieve joint C4I system interoperability. Chapter V builds on 
this to conduct a consolidated analysis of the entire action spectrum. Five examples are 
presented to illustrate that all C4I systems are not the same— each system has its own 
unique functional characteristics, and mission-specific qualities are identified. 

This chapter contains the following sections: consolidated initiative summary, 
similarities and differences, positive actions, further definition, mission-specific 
examples, and summary. The consolidated initiative summary section presents a vision, 
action, and baseline action matrix to analyze DoD and service initiatives. The similarities 
and differences and positive actions sections provide comments based on the consolidated 
analysis, while the further definition section identifies areas requiring additional 
development. Within the mission-specific examples section, five C4I systems that require 
extremely different functional parameters to support mission objectives are presented. 
Each example system subsection is divided into scenario, objective, mission analysis, and 
conclusions, and examples are further compared using a mission-specific area matrix. 
Finally, a summary section highlights the analysis observations. 

B. CONSOLIDATED INITIATIVE SUMMARY 

After reviewing the Joint Staff s C4IFTW documents, a general list of actions to 
achieve interoperability was prepared to compare DoD and service initiatives to ensure 
interoperability. From this, a consolidated initiative matrix. Table 2, was developed to 
compare service vision and implementation documents. Table 2 is divided into three 
major sections: vision, actions, and baseline actions (today). The vision identified within 
the C4IFTW concept is: 
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• Achieve global C4I joint interoperability, 

• That will allow any Warrior to perform any mission— anytime, any place, 

• That is responsive, reliable, secure, and 

• That is affordable. [Ref. 1] 

In Table 2, the vision section denotes the key documents that provide each 
service’s vision to achieve interoperability. The actions section contains explicit tasks 
outlined in the C4IFTW vision that must occur to attain this goal. Most of these actions 
are Mid-term Phase actions as outlined by the C4IFTW roadmap. Documents identified 
are not all-inclusive, but the list provides starting points that formalize system 
development to pursue interoperability. Finally, the baseline actions section contains 
publications and tools that are used by C4I system planners, designers, and developers 
today. 

As noted from the publication dates, the efforts to reach interoperability are 
continually evolving. The actual content from the publications provided may have the 
same purpose, but there are different objectives to meet individual service needs and 
expectations. 

C. SIMILARITIES AND DIFFERENCES 

As identified in Table 2, there are some similarities and differences between DoD 
and service actions. Even though this table provides differences from service-to-service, 
readers must address the specific content of these documents to identify the actual 
similarities and differences for each service. 

Every service has a vision, and each vision is tailored to support individual 
service needs and expectations. For example, the Army is the lead service with respect to 
the definition and development of technical architectures, while the Air Force has much 
success with employment of paperless information sharing and TRCs via the WWW. 
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D. POSITIVE ACTIONS 



Now that all services have a centralized focus and vision for interoperability, C4I 
system development promotes seamless interfaces that support the warfighter’s needs. As 
the basic building blocks for automated systems, standard data elements are essential for 
interoperability. Without a centralized starting point, efforts would be useless. 
Additionally, through modeling and simulation (M & S) techniques, C4I system 
designers and developers refine system parameters to ensure interoperability, which 
clearly assist with the definition of C4I systems. Even though the Air Force does not have 
a technical architecture to guide system development, they provide an exceptional on- 
line, up-to-date system development information source with TRCs. The ability to access 
existing standards in near real-time is invaluable to C4I system development. 

E. FURTHER DEFINITION 

Even with a centralized focus and vision for interoperability, there are several 
areas that must be further defined to streamline the development process: the definition of 
interoperability is mission-specific, existing standards (e.g., TAFIM) are too large and 
lack consistency [Ref. 8], and there is no formal process to develop interoperable systems 
from the DoD interrelated set of architectures. Depending on the mission purpose of a 
C4I system, individual functional characteristics may differ. Systems support the 
Warfighter and command and control functions, but interoperability is not always the 
same. For example, systems passing imagery in near real-time are not designed to pass 
information or data that is essential to counter a real-time threat, such as incoming enemy 
aircraft. The detail of interoperability must be defined from a C4I system’s functional 
mission. 

Existing development standards have grown too large for quality management. 
Using a paperless information sharing environment, as employed by the Air Force with 
TRCs, will make usable standards more accessible to planners, developers, and designers. 
The organization and format of TRCs provides clear guidance for system development. 
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Now that the DoD has defined a set of interrelated architectures, a process must be 
developed to use these tools to build interoperable systems. Currently, key people, 
systems engineers, etc., must continually be involved and formally track system design 
considerations to maintain interoperability. Inter-connectivity is as important as intra- 
connectivity for all C4I systems. 

F. MISSION-SPECIFIC EXAMPLES 

After recognizing that interoperability is mission-specific, identifying common 
parameters with different characteristics or values becomes more apparent. The following 
examples provide individual mission-specific profiles. From these examples, a mission- 
specific matrix is developed to demonstrate that there are quantitative differences for each 
system. 

1. Joint Air Defense Mission Profile 
a. Scenario 

Joint air defense consists of some combination of Army, Navy, Air Force 
and Marine systems working together to detect, track, identify, engage, and kill hostile air 
threats. ASCIET 95 (All Service Combat Identification Evaluation Team) tests at 
Gulfport, Mississippi, during September 1995, serve as an example of a joint air defense 
mission. The purpose of the ASCIET 95 program was to examine current multi-service 
combat identification (CID) procedures and capabilities on the battlefield and to identify 
necessary changes to systems interoperability, doctrine, and tactics, techniques and 
procedures (TTP). [Ref. 17] 

Figure 13 shows a schematic view of the ASCIET 95 scenario. The joint 
air defense system consisted of Navy Aegis cruisers stationed in the Gulf off of Gulfport; 
Army PATRIOT batteries stationed near Gulfport; a variety of aircraft overhead 
including an Air Force AWACS and RC-135, and Navy E-2s and a EP-3; and Marine 
close-in air defense systems including HAWK, Low Altitude Air Defense 
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(LAAD)/Forward Area Air Defense (FAAD) at Camp Shelby, approximately 50 miles 
north of Gulfport. [Ref. 1 7] 




Gulfport 



Aircraft Tracki 



OPFOR STRIKER 
ROUTING 



Aids 



Eglln 



BAWKrP 



J*. 



CAMP 



LAADJTAAD 



Figure 13. ASC1ET95 Scenario [From Ref. 17] 

During exercises, red opposition aircraft flew strike routes from Eglin 
AFB over the Gulf, then into Gulfport and Camp Shelby. Besides the assets mentioned 
above, the blue forces included intercept aircraft on CAP over the Gulf. The purpose of 
the exercises was to use the joint assets to detect, track, identify, and successfully engage 
the opposition force without incurring fratricide. [Ref. 1 7] 

b. Mission Objective 

The objective of the joint air defense mission was to maximize the 
probability of kill of all hostile air targets through the utilization of joint assets, while 
minimizing the loss of blue force assets due to enemy and friendly fire. [Ref. 17] 
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c. Mission Analysis 

A generic ASCIET95 C3I information flow diagram is shown in Figure 
14. The challenges are to provide timely connectivity between all multi-service C3I 
players and to effectively use ID and track information to support joint air defense 
operations. 




Figure 14. ASCIET95 Information Flow [From Ref. 17] 



In ASCIET95, the ID coordinator shown in Figure 14 was the Combat 
Identification Coordinator (CIDC) and the decision maker was the Regional Air Defense 
Commander (RADC). In addition an Interface Control Officer (ICO) had a key 
responsibility for providing a connectivity and data link picture to the RADC. [Ref. 17] 

Joint air defense operations (JADO) control responsibilities were 
decentralized to an assigned regional air defense commander (RADC) who exercised 
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overall command and control of all participating joint air defense forces. The RADC 
could divide the exercise airspace further into sectors (i.e., overwater/overland) and 
delegate JADO control responsibilities to a designated sector anti-air warfare commander. 
The purpose of designating a RADC was to minimize the overall number of independent 
decision makers within a given theater of operations, provide a centralized focal point for 
communications connectivity, and reduce the time for target ID-to-allocation-to- 
destruction process. [Ref. 17] 

The Aegis, E-2, TAOC, and E-3 functioned as the RADC at various times 
during ASCIET95 and provided final ID, allocation and engagement authority. [Ref. 1 7] 
The CIDC received ID data from various ID sources/providers and associated it with 
other track data to determine the correct ID. The CIDC then recommended that ID to the 
RADC. During ASCIET 95, Aegis, RC-135, EP-3 and the E-2C functioned as the CIDC 
to resolve probable ID recommendations from the other CID systems. [Ref. 1 7] 

All of the units participating as RADCs, CIDCs, ICOs, and shooters in 
ASCIET95 had to be linked by a communications network. There are a variety of 
communications links used by individual units, but no single link is common to all of the 
units. A communications architecture used in ASCIET95 that interfaces the various links 
is shown on Figure 15. 

During ASCIET95, it was observed that the effectiveness of the air 
defense system strongly depended on the time latency of data reaching the CIDC and then 
the RADC. The system began to lose ability to correlate data as information was delayed 
reaching the CIDC. As a result, multiple tracks of the same air vehicle were displayed 
and target IDs were miscorrelated with target tracks. In some cases when there were 
approximately 70 actual air vehicles (both blue and red combatants and background 
commercial air traffic) in the battle space, there were approximately 200 unique tracks 
being reported to the CIDC. This caused long differential delays of information coming 
from separate nodes as well as long overall delays of information coming from single 
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nodes, resulting in track reports of the same target from different reporting nodes falling 
outside of correlation windows. [Ref. 1 7] 




A= TADIL A 
B = TADIL B 
J = JTIDS 
I = IJMS 
C=TADIL C 
P = PADIL 
a = ATDL-1 
g= GBDL 
* = TAD1L-C 



Figure 15. ASCIET95 Communications Architecture [From Ref. 17J 



Delays were due to two factors: 1) disparities in communications systems’ 
bandwidths and delays at network translators led to bottlenecks in the flow of 
information; and 2) multiple nodes reporting the same information led to an overload of 
the tactical networks and resulted in long network cycle times. Differential delays 
between JTIDS and TADIL-A sources of information were reduced as message loading 
was reduced. Similarly, differential delays between sources of information from different 
nodes within the same JTIDS net and different nodes within the same TADIL-A net were 
reduced as a function of message loading. Thus, as illustrated in Figure 16, network 
loading and the control of the amount of information on a joint air defense system 
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network had an important effect on the ability of the system to successfully meet the joint 
air defense mission objective. [Ref. 17] 




Time Delay 



Figure 16. Number of Messages vs. Time Delay [Ref. 17] 
d. Conclusions 

Analysis of ASCIET95 indicates that all of interoperability requirements 
specified in the consolidated initiative matrix, Table 2, were met. All systems were linked 
using interoperable communications links and translators. Common message formats 
were used. However, there were additional mission-specific requirements that were not 
identified prior to conducting ASCIET95. These included maximum time delays in 
information reaching the combat ID coordinator, maximum differential delays in 
information being reported on the same target by different nodes, and a maximum 
network loading that depended on the particular network type. 

Current interoperability guidelines say that this type of additional mission- 
specific requirement will be identified during analysis of mission interoperability 
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requirements. However, these types of interoperability requirements can often only be 
discovered at the joint mission analysis level. Service-specific systems developed for 
service-specific missions may not be fully interoperable for joint missions if joint mission 
requirements have not been completely analyzed by the developing service. Therefore, 
there is a need to look at potential joint mission applications of individual service system 
developments and derive the necessary additional interoperability requirements arising 
from joint applications. 

Also, in the case of ASCIET95, there was an identified need to provide 
network control at the system level in order to reduce network delays. The requirement 
for network control at this level is a joint requirement and leads to the need for new 
hardware and/or software that is not a service-specific development item but is a joint 
development item. This identifies the need to have a joint service systems engineering 
organization responsible for some subset of interoperability issues. 

2. Joint Tactical Ballistic Missile Defense Mission Profile 

a. Scenario 

An example of a joint tactical ballistic missile (TBM) defense scenario is 
shown in Figure 17. Here we have assumed a littoral environment typical of a Korean 
theater. Army Theater High Altitude Air Defense (THAAD) and Patriot batteries are 
stationed on the land area. Future Aegis-based mid-tier missile defense systems are 
offshore. An Air Force future airborne laser (ABL) is overhead. The ABL will be capable 
of detecting, tracking, engaging, and killing TBMs during their boost phase at long stand- 
off ranges, up to 500 miles. THAAD and Aegis systems are mid-tier systems, capable of 
detecting, tracking, engaging, and killing TBMs during midcourse, after booster burnout 
and separation. PATRIOT is a lower tier defense system, capable of defending point 
targets and small areas. [Ref 18] 
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Figure 17. Joint Tactical Ballistic Missile Defense Scenario 



b. Mission Objective 

The objective of a joint tactical ballistic missile defense mission is to 
detect, track, engage, and perform complete raid attrition of the missile attack with the 
most efficient application of joint detection, tracking, and firepower capabilities. [Ref. 
18] 

c. Mission Analysis 

Figure 17 shows a schematic of a tactical ballistic missile flight, from 
launch to impact, as well as the approximate intercept regions of ABL, THAAD, AEGIS, 
and PATRIOT. 

ABL uses an infrared surveillance system and will detect a missile launch 
as soon as the missile breaks cloud top, approximately 40 seconds after launch for high 
cloud cover, or immediately upon launch in clear skies. ABL can rapidly develop a high 
accuracy track of the missile due to the high resolution and measurement accuracy of the 
electro-optical surveillance system. ABL can then engage and kill missiles during the 
boost phase, but since kill times using the directed energy weapon are on the order of 5- 
10 seconds ABL can only engage a subset of a large missile attack. [Ref. 18] 
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THAAD and AEGIS both perform exoatmospheric engagements on 
incoming missiles. Detection and tracking is performed by the THAAD ground-based 
radars and the AEGIS SPY radars, respectively. These radars detect targets after launch, 
at the radar horizon if they are looking in the proper area, and detection ranges are 
typically several hundred miles. The radars can be cued by ABL or by space-based 
sensors in order to focus their radar energy in a narrow beam that allows earlier detection 
of targets in some situations. Both systems develop fire control quality data for their own 
weapons. The AEGIS system might also incorporate the cooperative engagement 
capability (CEC) system which sends fire-control-quality track data from any CEC 
platform to all other CEC platforms. All CEC equipped platforms have the same set of 
radar processing software and hardware, and all CEC radars are gridlocked to high 
accuracy, resulting in all CEC platforms having identical track pictures. All CEC systems 
must be linked by a high (2-10 MHz) bandwidth system to allow data transfer and 
sensor gridlocking. PATRIOT detects, tracks, and engages leakers in the lower tier. 
PATRIOT can be cued by track data from THAAD and AEGIS. [Ref. 18] 

There are several interoperability issues that must be addressed in order to 
coordinate the system and achieve optimal joint performance. These issues are related to 
three levels of coordinated activity. First, the systems would have to be linked via 
communications systems in near real-time in order to provide cueing from tier to tier. 
Second, the systems would have to be linked via communications systems in real time or 
near real time in order to relay information concerning which targets have been engaged 
or are planned to be engaged, and which targets have been killed or failed to be killed. 
Failing to do this will result in multiple shots at the same target, leakers that are not 
engaged by any system, and extraneous track information due to unidentified interceptor 
missiles in-flight. Third, the systems could be linked in real time in such a way that 
would allow the theater battle management to be coordinated jointly, rather than relying 
on areas of responsibility. The advantage of joint battle management is that it allows 
optimal joint system performance provided information flow timelines can be met. Joint 
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battle management requires that all systems be linked via a communications system in 
real time; if CEC is to be used theater-wide then the communications system must be 
high bandwidth. Each participating system must have a battle management software 
system that is interoperable with all other system battle management software systems in 
terms of message formats, data elements, data accuracies and update rates; in terms of 
modularity of function (each individual system must be able to operate as a node in a 
distributed battle management system); and in terms of shared system information. The 
latter refers to the need to know exact details of every system’s state, including magazine 
state, in order to determine optimum distributed firing allocations. The requirements 
associated with these three levels of coordinated operation are listed in Table 3. [Ref. 18] 

d. Conclusions 

Analysis of the example joint tactical ballistic missile defense mission 
indicates that all of the interoperability requirements specified in Table 2 apply. All 
systems need to be linked using interoperable communications links and translators. 
Common message formats need to be used. However, there were additional mission- 
specific requirements that are not identified in Table 2. These include the need for real- 
time or near-real-time communications links so that maximum time delays in information 
reaching the various missile defense tiers is short enough to allow the required action by 
each tier. There is a need to transmit information that is internal to each of the systems to 
all other systems. This requires that the systems be designed such that there are real time 
transmittals of the internal information to external systems, and that the information is in 
a common format. Finally, level 3 of coordinated action requires that the internal 
functioning of the systems be designed such that battle management can be performed 
externally to each system as well as internally. Level 3 coordination also requires 
development of a joint battle management system with all of the interoperability 
requirements listed in Table 3. 
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Requirement 


Level 1 
Cueing 


Level 2 

Shared Engagement Data 


Level 3 

Joint Battle Management 


Comm Links 








Near real-time 


X 


X 


X 


Real-time 




or x 


X 


High bandwidth, 
real-time 






x (with CEC) 


Shared Data 








Engagements 




X 


X 


Kill assessment 




X 


X 


Tracks 




X 


X 


Sensor data 






x (with CEC, excluding 
ABL) 


System state data 






X 


Battle Management System 








Common software 
modularity 






X 


Common data 
dictionaries 






X 



Table 3. Derived Interoperability Requirements for Joint Tactical Ballistic Missile 

Defense [From Ref. 18]. 

3. Global Positioning System Profile 



a. Scenario 

The application of Global Positioning System (GPS) technology has 
increased the operational effectiveness of the armed forces. Military users in air, on land, 
and at sea receive accurate navigational information to guide their fighting force within 
every environment. GPS technology is being incorporated within networked positioning 
systems to increase the navigational accuracy at all levels. As the services conduct more 
joint operations and training, the need to share accurate positioning information becomes 
essential in the joint battlespace environment. Ground troops from one service may 
receive support from both air and sea units of another. Figure 18 illustrates an operational 
example where Navy aircraft are in direct support of Army ground troops. 
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GPS Constellation 




b. Mission Objective 

Within this proposed operational scenario, there is no established means 
for both air and ground forces to pass navigational and positioning information or 
coordinate operations. The lack of communications connectivity between air and ground 
elements is not only limited, but extremely dangerous for all entities involved. Figure 19 
represents a proposed operational architecture for the insertion of GPS data and 
establishment of critical communications links between air and ground units. 

Both air and ground units receive accurate positioning information from 
the GPS satellite constellation. As air and ground forces come within some predetermined 
range of each other, they begin to exchange positioning information through a 
temporarily established communications data link. 
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GPS Constellation 




Figure 19. Proposed Communications Architecture 



c. Mission Analysis 

The communications data link must be established early enough to provide 
positioning and navigational systems the time to process the information received. Also, 
force elements require ample time to observe, recognize, and react safely in support of 
real-time operations. If aircraft navigational systems use earth-centered coordinates and 
ground force positioning systems use flat earth coordinates for operation, systems require 
design parameters to perform information conversion and maintain functionality to 
support timely information flow. Predetermined range identification distances may need 
to be increased to support real-time operations. 
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d. Conclusions 

Both air and ground unit systems must use standard message formats and 
data elements, as specified in Table 2. The timing and accuracy of navigational data 
passed over a communications link between air and ground assets is critical for C4I 
systems of this type. Information must be timely to ensure C4I systems successfully 
support users and accurate enough to clearly represent the operational environment. The 
operational field of view greatly differs between aircraft and ground forces; therefore, 
accurate information is key to operational awareness. 

4. High Altitude Endurance Unmanned Aerial Vehicle Imagery Data 

Link Profile 

a. Scenario 

With lessons learned from Operation Desert Storm, the DoD found 
existing deficiencies in military Operations Other Than War (OOTW) which included the 
following: [Ref. 19] 

• Lack of broad area coverage 

• Limited Battle Damage Assessment (BDA) 

• Limited imagery dissemination to users 

• Limited information retrieval and distribution of intelligence data 

• Insufficient information to support Warfighter situational awareness 

• Insufficient high resolution imagery intelligence to support precision strikes 

• Reconnaissance that is not synchronized with the Warfighter 

The goal of the High Altitude Endurance Unmanned Aerial Vehicle (HAE 
UAV) is to provide quality extended reconnaissance that is responsive to the operational 
Warfighters’ needs. [Ref. 19] 
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b. 



Mission Objective 



The HAE UAV system is designed to provide near real-time (NRT) 
transmission of sensor imagery. The HAE UAV is a long dwell tactical surveillance and 
reconnaissance system that is capable of sustained high altitude operations over and into 
high threat areas. The system can operate at ranges in excess of 500 nautical miles from 
the launch area and loiter over the target area more than eight hours at an altitude greater 
than 45,000 feet. The HAE UAV employs both wideband line-of-sight (LOS) and 
moderate bandwidth satellite communications. [Ref. 19] 

The HAE UAV system contains a ground segment (mission control 
element (MCE)), ground communications element, launch and recovery element (LRE)), 
and support segment, which can be mission transportable to any theater of operations via 
three C-141 aircraft or equivalent loads. [Ref. 19] Figure 20 shows an operational view of 
the HAE UAV system. 

The system is designed to provide 24 hour continuous coverage of desired 
areas of interest using Synthetic Aperture Radar (SAR), Electro-Optic (EO), and Infrared 
(IR) sensors. The HAE UAV system can collect imagery of pre-planned areas of interest 
and quickly transmit the messages to combat commanders. [Ref. 19] 

c. Mission Analysis 

Figure 20 illustrates the program objective for using a satellite link for the 
transmission of imagery data from the aircraft to the MCE and selected imagery data 
from the aircraft to exploitation sites and tactical users. Using commercial satellites, data 
rates up to 50 Mbps are expected, while T-l rates are anticipated for links to tactical 
elements. Figure 21 illustrates the second method for imagery transmission from the 
aircraft to the MCE, exploitation elements, and tactical users. Through LOS systems, 
aircraft to MCE and exploitation elements data rates will increase to 137 Mbps, and links 
to tactical users will remain at T-L [Ref. 19] 
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Figure 20. In Theater Operational HAE UAV System using Commercial SATCOM 

(Ku Band) [From Ref. 19] 



HAE UAV 




C 2 V 



Figure 21. In Theater Operational HAE UAV System using Common LOS Data 

Links [From Ref. 19] 
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Different operational parameters change C4I system development. The two 
communications architecture options, illustrated in Figure 20 and Figure 21, create 
different requirements for the design and development of C4I systems to support both the 
MCE and exploitation elements — the interoperable designs have become mission- 
specific. 

d. Conclusions 

Since the LOS link from the aircraft to the tactical user remains the same, 
the development of the tactical users’ terminal requires no apparent change. The possible 
bandwidth limitations may even alter the operational use and employment of the system. 
New dissemination devices may have to be designed to support the distribution of 
imagery to the user. 

5. Close Air Support Profile 

a. Scenario 

Commanders use close air support (CAS) to focus firepower at the 
decisive place and time to achieve local combat superiority. Figure 22 depicts the flow of 
information from the time that friendly ground forces identify an enemy threat to the 
delivery of munitions on the target. Requests for CAS are usually on high frequency 
(HF), ultra high frequency (UHF), and very high frequency (VHF) radio voice nets. 
Tactical air control parties (TACPs), liaisons to ground forces, request CAS through the 
direct air support center (DASC); this may be an airborne C2 platform. By monitoring the 
Tactical Air Request (TAR) Net, battalion, regiment, and division level fire support 
coordination centers (FSCCs) approve requests by remaining silent and deny or alter 
requests as needed. [Ref. 20] 

b. Mission Objective 

CAS execution must be responsive to quickly support forward ground 
forces. To deter the fast-paced threats of the battlefield and to lower operational risks, 
offensive actions require immediate support to counter enemy intentions. 
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Figure 22. Information Flow for Close Air Support Requests 

c. Mission Analysis 

C4I systems must be flexible to support tactical users at multiple locations 
throughout the battlefield. The delay of information may place forces at risk. Even though 
CAS requests are not automated, there are many operational and design tradeoffs for C4I 
systems to ensure the request process can support real-time operations. Radio voice 
quality must be understandable for users to quickly identify essential information without 
retransmission. 

d. Conclusions 

As defined in Table 2, C4I system designs with common standards ensure all forces have 
reliable connectivity to conduct operations for real-time operations. If C4I systems do not 
facilitate CAS operations, the ability to access powerful lethal assets becomes limited. 
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High voice quality for systems alleviates the need for retransmission. If the request 
structure required data links, mission-specific parameters would change the design of the 
C4I system to achieve adequate interoperability. 

6. Mission-Specific Area Matrix 

In Table 4, mission profile areas are compared against one another using four of 
seven information quality criteria identified in Joint Publication 6-0. These criteria are: 
[Ref. 21] 

• Accuracy. Information that conveys the true situation. 

• Timeliness. Information that is available in time to make decisions. 

• Completeness. All necessary information required by the decision maker. 

• Security. Information that has been afforded adequate protection where 
required. 

From these criteria, an interoperability profile can be created. Each area is given a 
rating of high, medium (med), or low. For high, the C4I system attribute is essential or 
extremely relevant to support warfighter operations in real-time. For a medium rating, the 
system attribute is critical or relevant to support operations in near real-time (NRT), and 
low is important, but not as timely as NRT. 

Timeliness, accuracy, completeness, and security criteria for a C4I system can be 
quantified to better define a desired system’s requirements. As identified in Table 4, there 
are significant differences and the depth, level, detail, etc. of interoperability must be 
defined for each specific case. 
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Mission Profile Areas 
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Table 4. Mission-Specific Matrix 
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G. 



SUMMARY 



The DoD and services have initiated extensive visions to focus service efforts and 
achieve C4I system interoperability. Service actions are tailored to support individual 
needs and requirements, and standards are clearly defined and accessible to facilitate joint 
C4I interoperability development of future systems. Technical architectures and reference 
codes provide the guidance to design interoperable systems, but every system is not the 
same. Each system requires systems engineering analysis to ensure mission- specific 
parameters are met, and interoperability is more than seamless interfaces. In addition to 
timeliness, data and information may require different accuracy, completeness, and 
security levels for C4I systems to be functional. As noted within Table 2, a consolidated 
initiative matrix, every service has defined actions to achieve interoperability, but as the 
mission-specific examples of this chapter have demonstrated, as shown in Table 4, every 
case is different. C4I system purposes, missions, operational architectures, etc. affect 
system parameters that ensure interoperable systems are functional. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



The term interoperability has little meaning unless specific parameters 
are described and specified.. .[Ref. 1] 

C4I for the Warrior 
12 June 1992 

A. INTRODUCTION 

Even the original C4IFTW document identified that every system is not the same, 
and system parameters must be specified in detail. Building on the previous five chapters, 
this chapter identifies critical issues, provides direction, and recommends research areas 
requiring analysis. Chapter VI contains the following sections: conclusions, 

recommendations, and further research. The conclusions section formalizes analysis 
observations identified, and the recommendations section presents three initiatives to 
enhance the development of joint C4I systems. Finally, the further research section 
identifies four areas of study for DoD graduate students. 

B. CONCLUSIONS 

The definition of interoperability specified in Joint Publication 1-02 is vague 
regarding mission-specific C4I systems. As written, the definition requires the users, 
developers, planners, designers, etc. to further define interoperability for each mission- 
specific case. Alone, the ability to pass data through seamless interfaces does not ensure 
that systems receive information in a timely manner to render the system functional. 
Also, incomplete and inaccurate information can not only mislead, but slow down the 
warfighter’s decision making process. C4I systems must be designed to facilitate 
command and control and provide a well-defined picture of the battlespace without 
confusion. Interoperability must be defined for the system frame of reference and the use 
of the C4I system. 
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c. 



RECOMMENDATIONS 



1. C4I System Mission Interoperability Profiles 

As identified in Joint Publication 6-0, information flow must be nearly 
instantaneous both vertically and horizontally within an organizational structure [Ref. 
21]. This publication further describes the information quality criteria listed in Table 5. 



Accuracy 


Information that conveys the true situation 


Relevance 


Information that applies to the mission, task, or situation at hand 


Timeliness 


Information that is available in time to make decisions 


Usability 


Information that is common, easily understood format and displays 


Completeness 


All necessary information required by the decision maker 


Brevity 


Information that has only the level of detail required 


Security 


Information that has been afforded adequate protection where required 



Table 5. Information Quality Criteria [From Ref. 21] 



From accuracy, timeliness, completeness, and security information quality 
criteria, an interoperability profile can be created. These criteria or attributes for a C4I 
system can be quantified to better define a desired system’s requirements. For example, a 
system that transports essential air defense information must be more accurate, timely, 
and complete to react to a real-time threat than a system that passes imagery. This is a 
simplified example, but consider the quantifiable differences for each item of criteria. C4I 
systems must be interoperable, but to what level? If an air defense system is considered 
interoperable and accurately passes complete information both vertically and 
horizontally, but fails to pass this information in a timely manner, then the system is 
useless. 

Establishing profiles for C4I systems will further define and describe user 
requirements and assist system designers and developers to ensure adequate levels of 
interoperability. To just identify interoperable levels provides no quantifiable 
characteristic to follow. 

Table 6 contains a proposed framework to establish C4I system profiles. 
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C4I System 
Attribute 


Proposed Definition 


Quantifiable 

Measure 


Accuracy 


Data accuracy that conveys the true situation 


percentage or Bit 
Error Rate 


Timeliness 


Time allocated for data to reach a C4I system so it may be 
processed in time to render the system effective 


measured in seconds 
or milliseconds 


Completeness 


Data amount that conveys the true situation 


percentage 


Security 


Security level required for system operation 


(e. g., unclass, 
secret, etc.) 



Table 6. Proposed Interoperability Profiles 



Profiles must be initially established as C4I system requirements are defined and 
optimized through modeling and simulation and joint testing processes. The overall 
purpose of mission-specific profiles is not to create unrealistic requirements and delay the 
development process for C4I systems, but to establish thresholds to guide designers from 
requirement definition through initial design, modeling and simulation, and subsequent 
system upgrades. As DoD guidance and technology advance, profiles should be updated 
to better support interoperability of like systems— they, too, are continually evolving. 

2. Joint Scenario Testing 

DoD Directive 4630.5, Compatibility, Interoperability, and Integration of C3I 
Systems, states that all C4I systems are considered joint unless exemptions are granted. 
As indicated by the ASCIET95 series of tests, systems must be modeled and simulated 
and tested in joint scenarios. Interoperability is much more than reliable interfaces. C4I 
systems may seamlessly interface, but they are not interoperable if the traffic load from 
joint and service specific systems creates time delays rendering the overall network of 
systems ineffective. Joint scenario modeling and simulation and testing is essential to 
ensure interoperability of networked systems. 

3. On-line Interoperability Standards 

The US Air Force’s development of Technical Reference Codes (TRCs) has 
dramatically enhanced progress to achieve interoperability for all Air Force C4I systems. 
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Up-to-date standards and system development information can be quickly accessed to 
guide system planners, developers, and designers within the Air Force. The logical 
organization of TRC development standards is an effective tool for the commercial 
industry as well as service personnel. As long as TRCs are adequately maintained, the 
time from requirements definition to placing the C4I system in the hands of the 
warfighter will be reduced. All services must adopt this real-time concept of operations. 

D. FURTHER RESEARCH 

1. Further Develop C4I System Interoperability Profiles 

From today’s proposed interoperability levels, further develop C4I system profiles 
to quantify design requirements of military systems. 

2. Model a System Development Process 

Using commercial industry and theoretical automated information system 
development techniques, model a system development process that uses the DoD 
interrelated set of architectures as the starting point. 

3. Identify Key Data Repository Elements 

Compare commercial industry and military automated information system 
development techniques to identify similarities and differences and key data repository 
elements for military application. 

4. Further Develop the Copernicus... Forward Vision 

Further develop the Copernicus... Forward vision to strengthen the US Navy and 
Marine Corps team and enhance forward presence operations. 
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